Bataille avec l'IA

Au centre de Quimper se trouve le Sélène Café, notre coffee shop préféré.

Au centre du Sélène Café se trouve un petit meuble rempli de jeux de société vers lequel ma fille de 4 ans se rend systématiquement après avoir commandé son chocolat chaud.

9 fois sur 10, elle en revient avec Argine, César et Judith, accompagnés de leur 49 copines : les 52 cartes au grand complet !

C’est l’heure de la bataille.

Un peu de contexte #

Pour jouer à la bataille, il suffit de 2 choses :

• avoir une main fonctionnelle
• savoir dire de 2 cartes laquelle est la plus forte

Zéro stratégie, zéro décision à prendre : ma fille adore !

C’est aussi un jeu très, très, TRÈS LONG… sur plusieurs dizaines de parties jouées, nous n’en avons jamais terminé aucune.

Partie après partie me vient naturellement cette question saugrenue :

Combien de temps dure en moyenne une partie de bataille ?

Hélas, si nous ne finissons jamais aucune partie, nous n’aurons jamais ne serait-ce que l’embryon d’une réponse…

Mais, arrêtons-nous un instant.

La bataille, c’est un jeu :

• aux règles simplissimes
• où il n’y a aucune décision à prendre

Pourquoi ne pas simuler quelques dizaines de milliers de parties de bataille pour découvrir au bout de combien de temps en moyenne dure une partie ?

Une IA générative bien sentie devrait même pouvoir s’en sortir !

“Tonton Claude, dessine-moi 10 000 parties de bataille” #

J’ai donc formulé à Claude la demande suivante :

Génère une simulation du jeu de bataille,
décrit ici : https://en.wikipedia.org/wiki/War_(card_game).
L'idée est de voir quelle est la durée moyenne d'une partie.

Deux minutes plus tard, j’avais mes résultats, tout beaux, tout propres !

Pour 10 000 parties simulées :

• Durée moyenne d’une partie : 448 tours (médiane 336 tours)
• Partie la plus courte : 26 tours
• Partie la plus longue : 3 597 tours
• 95 % des parties en dessous de 1 176 tours

Et, cerise sur le gateau, Claude me propose un joli graphique représentant le nombre de batailles se produisant par partie (une bataille = les deux joueurs posent tous deux une carte de même rang).

suivi par la répartition du nombre de tours par partie :

Bon, à ce stade, nous sommes d’accord : les parties de bataille peuvent durer très longtemps.

Mais si je regarde les deux premiers bâtons de la dernière figure, il se trouve que dans un peu plus de 20 % des cas de la simulation, la partie se termine en moins de 200 tours.

Ça me gêne, je trouve cette proportion un peu élevée.

“Merci Tonton Claude, je vais voir ce que je trouve de mon côté !”

L’humain, cette machine à bugs #

Aussitôt dit, aussitôt fait : je code une simulation de bataille toute simple en quelques minutes - je me pose tout de même un instant pour ne pas écrire n’importe quoi dans les situations de bataille. Et hop, tout est prêt !

Je lance une simulation avec 10 000 parties.

• 30 secondes, je regarde l’heure.
• 1 minute, je commence à froncer.
• 2 minutes, c’est pas possible il y a un problème.

Arrêt de la simulation, réduction du nombre de parties : de 10 000 à 100 parties.
Je relance.
Même constat :

• 40 % des parties n’ont ni vainqueur, ni perdant après plus de 100 000 tours (contre 100% des parties qui finissent selon la simulation de Claude)
• les parties qui se terminent durent en moyenne 1 700 tours (contre 448 tours selon la simulation de Claude)

J’affiche à l’écran les détails de chaque tour. Tout est correct.

Tout est correct, mais la simulation finit toujours par tomber sur une partie qui ne termine JAMAIS.

Or si des phénomènes cycliques apparaissent, c’est qu’on maintient quelque part un certain ordre dans le jeu, une forme d’ordre involontaire qui se propage durant la partie.

Mon regard glisse vers le moment du jeu auquel je n’avais jusqu’alors prêté aucune attention : la réintégration du pli dans le paquet de cartes du gagnant.

Tout semble OK, mais un rapide coup d’oeil sur le code généré par Claude me met la puce à l’oreille :

random.shuffle(table)

Cette fonction bien connue permet de mélanger les cartes du pli avant de les réintégrer dans la pile.

Dans son immense sagesse, Claude mélange les cartes avant de les réintégrer dans le jeu du gagnant.

Sagesse ? Vraiment ?

Passer implicitement pour un blaireau #

Que s’est-il passé ? #

Claude ne s’est pas arrêté à la page wikipedia de la bataille, mais il est allé visiter une dizaine d’autres pages. Certaines d’entre-elles présentant effectivement la possibilité de mélanger la pile de cartes gagnées avant d’en refaire sa pile principale (comme cette page, celle-ci, celle-là ou encore cette autre page).

Mais aucune page ne mentionne le fait de mélanger les cartes de chaque pli.

Et pour cause ! Les cartes sont censées se mélanger de manière naturelle, au gré des différents tours de jeu.

Claude a implémenté dans la simulation le comportement qu’il estimait le plus adéquat, non pas d’après la source fournie, ni d’après les sources secondaires, mais probablement d’après les données auxquelles il a été exposé durant sa propre phase d’apprentissage.

En d’autres termes, Claude a pris une décision implicite qui a eu un résultat “statistiquement significatif”.

Quand la liberté nuit #

Le problème des choix implicites n’est pas nouveau : en 2016, Sara Steegen et son équipe ont montré qu’en effectuant différents pré-traitements (légitimes) sur un jeu de données brutes, les résultats obtenus pouvaient être significativement différents ¹.

Dans toute situation, les degrés de liberté forment une source importante de biais parce qu’ils induisent des choix implicites ou même inconscients.

C’est notre cas ici : doit-on, ou non, mélanger les cartes avant de ranger le pli ?

L’article de Steegen propose une approche radicale consistant en gros à lister toutes les approches alternatives pertinentes, les exécuter une par une et évaluer ainsi la solidité du résultat obtenu : c’est l’analyse multiverse.

OK, Romain, on a compris, Claude a failli ruiner ta simulation de bataille, simulation qui a d’ailleurs probablement déjà été lancée des milliers de fois par d’autres avant toi.
Et alors ?

Plongée dans l’infini avec l’impatience de ma fille #

Ma fille n’est pas très patiente lorsqu’il s’agit de jouer à la bataille : après quelques tours de jeu, elle commence à jouer très rapidement en plaçant systématiquement sa carte la première. Se faisant, elle détruit l’aléatoire naturel du pli… nous projetant sans le vouloir dans des parties infinies !

Cet exemple simple illustre un aspect important des outils d’IA générative : s’ils effacent la complexité entre l’idée d’un projet et sa réalisation pratique, c’est au prix d’un ensemble de choix réalisés au nom de l’utilisateur, sans que celui-ci en soit nécessairement informé.

On retombe donc sur un grand paradoxe des LLMs. Ils permettent d’abstraire le “comment” d’une tâche pour arriver à un résultat, mais ce résultat n’a de valeur que si l’utilisateur en vérifie les étapes.

Le mathématicien Terence Tao - médaillé Fields en 2006 - partage cette image éloquente :

Utiliser des outils d’IA [pour résoudre certains problèmes] revient à prendre un hélicoptère pour vous larguer directement à destination. Vous manquez tous les bénéfices du voyage en lui-même. Vous arrivez directement à destination, ce qui ne constituait qu’une partie de la valeur associée à la résolution de ces problèmes.
— Terence Tao²

Claude m’a amené à destination en un claquement de doigts, mais en contournant soigneusement une découverte inattendue et bien plus intéressante. En rendant indolore et presque indicatif le processus de création et de recherche, les IA génératives condamnent la découverte fortuite (que ces messieurs les Anglais appellent serendipity).

En utilisant un outil d’IA générative, j’ai failli rater l’infini.